Third-Party Routing Server or AudioCodes Routing Manager
You can employ a remote, third-party routing server or
For more information on ARM, refer to the documents ARM User's Manual and ARM Installation Manual
For SBC calls, when the device receives an incoming call (SIP INVITE, NOTIFY or MESSAGE), it searches the IP-to-IP Routing table for a matching routing rule. If the routing rule is configured to use a routing server ('Destination Type' parameter configured to Routing Server), the device sends a request to the routing server or ARM for an appropriate destination.
The request is sent to the routing server or ARM using an HTTP Get Route message. The request contains information about the call (SIP message).
The routing server or ARM uses its own algorithms and logic in determining the best route path. The routing server or ARM manages the call route between devices in "hops", which may be spread over different geographical locations. The destination to each hop (device) can be an IP address (with a port) or IP Group. If the destination is an IP address, even though the destination type (in the IP-to-IP Routing table) is an IP Group, the device only uses the IP Group for profiling (i.e., associated IP Profile etc.). If multiple devices exist in the call routing path, the routing server or ARM sends the IP address only to the last device ("node") in the path.
Once the device receives the resultant destination hop from the routing server or ARM, it sends the call to that destination. The routing server or ARM can provide the device with an appropriate route or reject the call. However, if for the initial request (first sent Get Route request for the call), the routing server or ARM cannot find an appropriate route for the call or it doesn't respond, for example, due to connectivity loss (i.e., the routing server or ARM sends an HTTP 404 "Not Found" message), the device routes the call using its routing tables. If the Get Route request is not the first one sent for the call (e.g., in call forwarding or alternative routing) and the routing server or ARM responds with an HTTP 404 "Not Found" message, the device rejects the call.
This HTTP request-response transaction for the routing path occurs between routing server or ARM and each device in the route path (hops) as the call traverses the devices to its final destination. Each device in the call path connects to the routing server or ARM, which responds with the next hop in the route path. Each device considers the call as an incoming call from an IP Group. The session ID (SID) is generated by the first device in the path and then passed unchanged down the route path, enabling the routing server or ARM to uniquely identify requests belonging to the same call session.
Communication between the device and routing server or ARM is through the device's embedded Representational State Transfer (RESTful) API. The RESTful API is used to manage the routing-related information exchanged between the routing server or ARM (RESTful server) and the device (RESTful client). When you have configured the device with connection settings of the routing sever or ARM and the device starts-up, it connects to the routing server or ARM and activates the RESTful API, which triggers the routing-related API commands.
The following figure provides an example of information exchange between devices and the routing server or ARM for routing calls:
The routing server or ARM can also manipulate call data such as calling name, if required. It can also create new IP Groups and associated configuration entities (e.g., IP Profiles), if necessary for routing. Multiple routing servers can also be employed, whereby each device in the chain path can use a specific routing server. Alternatively, a single routing server or ARM can be employed and used for all devices ("stateful" routing server).
The device automatically updates (sends) the routing server or ARM with its' configuration topology regarding SIP routing-related entities SRDs, SIP Interfaces, IP Profiles, and IP Groups) that have been configured for use by the routing server or ARM . For example, if you add a new IP Group and enable it for use by the routing server or ARM, the device sends this information to the routing server or ARM. Routing of calls associated with routing-related entities that are disabled for use by the routing server or ARM (default) are handled only by the device (not the routing server or ARM).
In addition to regular routing, the routing server or ARM also supports the following:
| ■ | Alternative Routing: If a call fails to be established, the device "closest" to the failure and configured to send "additional" routing requests (through REST API - "additionalRoute" attribute in HTTP Get Route request) to the routing server or ARM, sends a new routing request to the routing server or ARM. The routing server or ARM may respond with a new route destination, thereby implementing alternative routing. Alternatively, it may enable the device to return a failure response to the previous device in the route path chain and respond with an alternative route to this device. Therefore, alternative routing can be implemented at any point in the route path. If the routing server or ARM sends an HTTP 404 "Not Found" message for an alternative route request, the device rejects the call. If the routing server or ARM is configured to handle alternative routing, the device doesn't make any alternative routing decisions based on its alternative routing tables. |
If the device sends an HTTP Get Route request and the routing server or ARM responds with a REST API attribute "action" that is set to the value 'continue', the device routes the call using its IP-to-IP Routing table. It uses the routing rule located after the original routing rule used to query the routing server or ARM ('Destination Type' set to Routing Server) whose 'Alternative Route Options' parameter is configured to Route Row. This routing can be used at any stage of the call (e.g., after alternative routing failure by the routing server or ARM, or after receiving a REFER/3xx).
| ■ | Call Forking: The device can fork calls according to the routing server or ARM. When the device finds a matching routing rule in the IP-to-IP Routing table that is configured with the Routing Server destination, it sends an HTTP Get Route request to the routing server or ARM. When it receives a successful response from the server or ARM, the device sends an INVITE message to a destination based on the response. If the routingMethod in the response from the routing server or ARM is "fork", the device sends another HTTP Get Route request to the server or ARM and upon a successful response, sends another INVITE to another destination based on the response, and so on. This call forking process continues until no routingMethod is received from the server or ARM, or it is set to “seq”, or there is a failed response from the server or ARM. If all the contacts fail (4xx), the device falls back to an alternative route, if exists, from the routing server or ARM. If 3xx is received for any of the forked destinations, the device handles it after all the forked INVITEs have been terminated. |
The routing server or ARM can also provide the device with a "no-answer timeout" in the response. If the called IP party doesn't answer the call within this interval, the device disconnects the session or forks the call (delayed call forking). If provided, this value overrides the [SBCAlertTimeout) parameter.
| ■ | Call Status: The device can report call status to the routing server or ARM to indicate whether a call has successfully been established or failed (disconnected). The device can also report when an IP Group (Proxy Set) is unavailable, detected by the keep-alive mechanism, or when the CAC thresholds permitted per IP Group have been crossed. |
| ■ | Credentials for Authentication: The routing server or ARM can provide user (e.g., IP Phone caller) credentials (username-password) in the Get Route response, which can be used by the device to authenticate outbound SIP requests if challenged by the outbound peer, for example, Microsoft Skype for Business (per RFC 2617 and RFC 3261). If multiple devices exist in the call routing path, the routing server or ARM sends the credentials only to the last device ("node") in the path. |
Alternatively, the device can authenticate incoming SIP requests (INVITE or REGISTER) from User-type IP Groups, by first obtaining (REST-based API query) the user's password from the routing server or ARM where it is stored. When this feature is enabled and the device receives an incoming SIP dialog-initiating request, it sends the REST API command getCredentials in the Get request to the routing server or ARM. The name of the user whose credentials are requested is obtained from the SIP From header when authenticating an INVITE message, and from the To header when authenticating a REGISTER message. The routing server or ARM sends a 200 response to the device containing the password (if the requested user exists). The device then sends the challenge back to the user. The user resends the request with a SIP Authorization header (containing a response to the challenge), and the authentication process continues in the usual manner. If the device doesn’t receive a password, it rejects the incoming dialog (SIP 404). To enable this authentication type, you need to configure the IP Group's 'SBC Server Authentication Type' parameter to ARM Authentication (see Configuring IP Groups). Note that the routing server or ARM doesn't authenticate users, but only helps the device to process the SIP Digest authentication by providing the user credentials.
| ■ | QoS: The device can report QoS metrics per IP Group to the routing server or ARM which it can use to determine the best route (i.e., QoS-based routing). For more information, see Configuring QoS-Based Routing by Routing Server. |
| ■ | Call Preemption for Emergency Calls: If you enable call preemption for emergency calls (e.g., 911) on the device, the routing server or ARM determines whether or not the incoming call is an emergency call and if so, handles the routing decision accordingly (i.e., preempts a non-emergency call if the maximum call capacity of the device is reached in order to allow the emergency call to be routed). To enable call preemption for emergency calls, use the [SBCPreemptionMode] parameter . |
| ■ | Registration status: The device can periodically synchronize its registration database of SIP user agents (endpoints) with the routing server or ARM to keep it up to date, enabling the routing server or ARM to use this information to perform correct and optimal routing decisions. To enable this functionality, see Enabling Registration Status Services. |
| ➢ | To configure routing based on routing server or ARM: |
| 1. | For each configuration entity (e.g., IP Group or IP Profile) that you want routing done by the routing server or ARM, configure the entity's 'Used By Routing Server' parameter to Used: |
| 2. | Configure an additional Security Administrator user account in the Local Users table (see Configuring Management User Accounts) that is used by the routing server or ARM (REST client) to log in to the device's management interface. |
| 3. | Configure the address and connection settings of the routing server or ARM, referred to as a Remote Web Service and an HTTP remote host (see Configuring Remote Web Services). You must configure the 'Type' parameter of the Remote Web Service to Routing, as shown in the example: |
| 4. | In the IP-to-IP Routing table, configure the 'Destination Type' parameter of the routing rule to Routing Server (see Configuring SBC IP-to-IP Routing Rules): |
